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SCCU/MCCU  Characteristics  for  Autodin  II 


The  purpose  of  this  report  is  to  characterize  as  accurately  as  our  present 
knowledge  will  permit,  the  size,  performance,  and  cost  of  the  Single  Channel 
and  Multi-channel  control  units  for  the  Autodin  II  [1]  network.  These  units 
act  as  interfaces  between  the  network  and  a host  which  wishes  to  use  the 
network  without  making  modification  to  its  existing  I/O  facilities  (or,  at 
least,  without  making  very  significant  modification  to  these  facilities). 


It  is  assumed  that  these  units  consist  of  three  basic  components: 

(a)  Segment  Interface  Protocol  Program  (SIP) 

(b)  Transmission  Control  Program  (TCP) [2 ,3] 

(c)  Host  Specific  Interface  (HSI) 


At  Stanford  University's  Digital  Systems  Laboratory  (SU-DSL),  we  have  engaged 

★ 

in  a research  program  to  experiment  with  the  TCP,  its  interface  to  several 
networks,  and  its  interface  to  several  user  programs.  The  prototypical  SCCU 
has  been  built  on  a Digital  Equipment  Corporation  (DEC)  LSI-11  (PDP-11 /03)  and 
interfaced  to  thQ  ARPANET  and  the  Packet  Radio  Network  (a  DARPA/IPTO  research 
network  using  ground  packet  radio  repeaters  to  provide  the  packet  communication 
facility).  The  equivalent  MCCU  has  been  built  for  a DEC  PDP-11/20  and  has 
also  been  interfaced  to  the  ARPANET  over  a Very  Distant  Host  Interface  [4, 
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The  PDP-10  MCCU  version  runs  under  the  TENEX  operating  system  [5]  and  is 
written  in  BCPL  [6,7],  a high  level,  ALGOL-like  block-structured  language. 

Both  the  SU-DSL  and  BBN  PDP-11  MCCU's  are  also  written  in  BCPL  and  run  under 
the  ELF  (8,9,10]  operating  system.  The  SU-DSL  SCCU  is  written  in  MACN-11 
[11],  a macro-assembly  language  for  the  PDP-11. 

At  the  time  of  this  writing,  all  these  systems  were  functioning  experimentally, 
but  there  existed  some  implementation  deficiencies  which  affected  some  of  the 
performance  measurements.  We  expect  these  problems  to  be  remedied  during  the 
second  quarter  of  1976,  and  thus,  the  performance  described  herein  can  be 
taken  as  a lower  bound  rather  than  an  upperbound. 

2.  The  Single  Channel  Control  Unit 
2.1  Physical  characteristics 

At  SU-DSL,  an  SCCU  was  constructed  using  a DEC  LSI-11  system  composed  of: 

1.  LSI-11/03  CPU 

2.  8K  16  bit  RAM  memory 

3.  DRV-11  8 bit  general  purpose  full  duplex  interface 

4.  DLV-11  TTY  interface 

5.  8 bit  1822  HOST/IMP  interface  [built  by  SU-DSL,  see  reference  12] 

The  hardware  cost  of  this  configuration,  including  the  1822  interface,  is 
approximately  $3600.  There  is  room  in  the  configuration  for  an  additional 
pair  of  double-height  circuit  boards  which  could  be  used,  for  instance,  to  add 
a floppy  disk  controller,  or  more  memory,  or  an  additional  TTY  interface  [e.g. 
to  allow  for  a combination  of  hardcopy  and  CRT  devices  at  the  SCCU  workstation]. 
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The  1822  interface  is  interrupt  driven  (for  each  8-bit  byte  transferred  in  either 
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direction)  and  is  consequently  not  especially  efficient  (but  it  is  small  and 
cheap!).  The  interface  has  a maximum  signalling  bandwidth  of  50kb/sec. 

A DMA  version  of  the  1822  interface  is  under  development  by  Collins  Radio 
Company;  it  will  require  more  space  (probably  two  double  height  circuit  boards), 
but  will  probably  achieve  higher  maximum  bandwidth. 


The  SCCU  at  SU-DSL  is  configured  as  an  inter-network  terminal  controller.  It's 
software  (all  of  which  is  written  in  the  MACN-11  assembly  language)  includes 
a version  of  TCP  called  TCP0  [13]  and  a version  of  the  standard  ARPANET  TELNET 
[14,15].  TCP0  conforms  to  all  the  standard  TCP  conventions  in  reference  [2], 
except  that 

1.  It  manages  only  a single  TCP-TCP  connection. 

2.  It  generates  only  single  packet  ARPANET  messages  (but  will  receive 
multi  packet  messages). 

3.  It  does  not  reassemble  fragmented  segments 

4.  It  responds  to,  but  does  not  send  Desynchronization  requests  [it 
need  not  do  this,  since  it  can  always  remember  the  last  sequence 
number  used  on  its  previous  connection]. 

5.  It  responds  to,  but  does  not  send  INTerrupts.  [This  will  be 
remedied  shortly,  and  is  not  expected  to  require  much  additional  code]. 


The  TELNET  will  only  negotiate  echo  mode  and  "Go  Ahead"  character  options, 
rejecting  all  others;  aside  from  that,  it  implements  the  full  basic  TELNET. 

The  table  below  illustrates  the  size  of  the  various  components  of  our  SCCU. 

The  size  does  not  vary  significantly  for  the  ARPANET  versus  PRNET  versions, 
but  if  the  Station  to  Packet  Repeater  Protocol  (SPP)  [16]  is  required  for  PRNET 
access,  the  size  may  increase  by  as  much  as  IK  words  of  code  and  buffer  space. 
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As  can  be  seen  from  Table  I,  the  software  to  support  a terminal  using  TCP0 
and  TELNET  occupies  slightly  less  than  half  the  available  space.  Our  per- 
formance measurements  on  this  configuration  indicate  that  it  could  reasonably 
support  more  than  one  terminal,  or  an  RJE  station.  Of  course,  the  SCCU  is 
capable  of  supporting  only  a single  TCP  connection  at  a time.  Since  the  TCP0 
code  is  re-entrant,  it  could  be  used  to  support  more  than  one  connection. 

This  would  require  an  increase  in  "operating  system"  complexity  [currently  it 
manages  two  processes:  input  and  output],  and  more  buffer  space.  The  author 

of  the  TCP0  estimates  that,  at  worst,  the  code  might  double  in  size  if  general 
multiple  connection  service  were  to  be  supported.  Assuming  a comparable  increase 
in  buffer  requirements  for  each  new  connection,  we  estimate  that  an  MCCU  version 

of  the  TCP0/TELNET  programs  might  occupy  5100  + n x 500  words,  allowing  up  to 
★ 

five  connections  in  the  8K  words  of  space  available.  These  estimates  are 
probably  unduly  pessimistic. 

An  SCCU  which  acts  as  a host  interface  to  AUTODIN  II  will  not  contain  the 
TELNET  software.  It's  size  is  thus  reduced  by  1454  words  to  2542  words,  but 
the  addition  of  SIP  and  Host  specific  software  may  bring  the  total  back  up  to 
4K  or  more.  We  believe  that  for  single  connection  host  support,  the  current 
configuration  should  be  adequate,  although  we  believe  that  a DMA  1822  interface 
would  be  appropriate  to  improve  the  basic  bandwidth  of  the  system. 

In  terms  of  programming  effort,  we  estimate  that  the  TCP0  required  3-6  man- 
months  of  effort  (by  an  extremely  capable  systems  programmer)  and  for  the 
TELNET,  about  the  same.  A multi-connection  version  of  TCP0  might  require 

* Assuming  multiconnection  TCP0  = 2700,  OS  + controllers  + basic  buffers  = 1200, 
TELNET =1200  and  500  words  of  buffer  and  table  per  connection,  "n" 
the  number  of  connections. 
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DCA-SCCU/MCCU  Table  I 


SCCU  Software  Configuration 
(all  sizes  in  decimal  16  bit  words) 


(a) 

Interrupt  vectors 

128 

(b) 

Operating  system 
(includes  40  words  of 
stack  space) 

150 

(c) 

* 

Buffers 

(1)  input  buffer 

512 

(2)  output  buffer 

128 

(3)  reassembly  buffer 

190 

(4)  retransmission  buffer 

190 

(5)  TELNET  buffers 

80 

(d) 

1822  interface  driver 

113 

(e) 

TCB  (connection  status) 

37 

(f) 

TCP0  program 

1337 

(g) 

TELNET  program  and  tables 

1168 

TOTAL 

3996 

TABLE  I 

* Note:  These  buffers,  though  n words  each,  actually  accommodate  n 

bytes,  owing  to  special  control  information  about  each  byte 
which  must  be  kept  in  the  circular  buffer. 
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6-12  man  months  of  effort,  but  we  haven't  attempted  to  do  this,  so  the 
estimate  is  subject  to  the  usual  doubts. 

A complex  SIP  (e.g.  the  PRNET  SPP  [16])  might  require  an  additional  6-12 
man  months,  and  a complex  host  interface,  the  same.  We  have  not  had  experience 
with  the  programming  of  front-end  types  of  interfaces.  The  UCL  (University 
College  London)  PDP-9  interface  to  a 360/195  (standard  ARPANET  NCP,  TELNET, 
and  file  transfer  protocol  (FTP)  translated  into  0S  360/RJE  protocol) 
required  on  the  order  of  3 man  years  of  effort.  Our  own  FTP  (for  standard 
ARPANET  application  under  ELF)  was  written  in  assembly  language  in  about  3-6 
man  months. 

We  conclude  that,  starting  from  scratch,  a full  SCCU  with  relatively  complex 

host  and  network  interfaces  might  require  from  15  to  30  man  months  of  effort 

and  for  a multi-connection  version  of  SCCU,  perhaps  a total  of  18  to  36  man 

months.  All  these  figures  assume  the  programmers  are  of  the  quality  one  finds 

★ 

in  the  universities  under  the  cognomen  "hacker  ." 

2.2  SCCU  Cost  Estimates 

The  basic  cost  of  the  LSI-11  hardware  in  our  SCCU  is  shown  in  Table  II 
below.  If  the  simple  1822  interface  were  to  be  replaced  with  a DMA  version, 
we  estimate  that  the  cost  would  increase  to  about  $4120  [$1,000  extra  for  the 
DMA  1822,  dropping  the  DRV-11  and  the  SU-DSL  1822]. 

* Hacker:  someone  who  would  rather  chase  bugs  in  a computer  program  than 

almost  anything  else. 
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1 

* 

SU-DSL  SCCU  Cost 

1.  LSI-11/03  + 4K  memory 
+ DLV-11  TTY 

2.  DRV-11 

3.  4K  RAM  memory 

4.  SU-DSL  1822  interface 
TOTAL 

TABLE  II 


$2495 

195 

625 

250  [est.] 
$3565 


1 


w 


V: 


DCA-SCCU/MCCU  Page  6 

2.3  SCCU  Performance  Estimates 

It  is  important  to  note  two  characteristics  of  the  SU-DSL  SCCU  before 
considering  its  performance.  First,  the  LSI-11/03  is  quite  slow;  instructions 
may  take  5-7  microseconds  to  complete.  Second,  the  SU-DSL  1822  interface, 
while  full  duplex,  requires  interrupt  service  for  every  8-bit  byte  that 
passes  in  or  out  of  the  LSI-11  memory.  Consequently,  the  interrupt  service 
loop  constitutes  a potential  bottleneck  in  achievable  bandwidth.  This  bottle- 
neck could  be  remedied  by  the  use  of  a DMA  1822  interface  and/or  a faster  CPU. 

Table  III  illustrates  the  full  duplex  bandwidth  of  the  TCP0,  driven  by  a 
simple  message  generator,  but  utilizing  an  internal  software  loop,  rather  than 
passing  out  the  1822  interface  and  back  in  again.  This  gives  an  upperbound  on 
the  software  speed  of  the  TCP0.  All  numbers  are  decimal,  and  those  representing 
bandwidth  are  full-duplex  (i.e.  if  the  bandwidth  is  x bits/sec,  then  the  input 
and  output  channels  are  each  operating  at  x bits/sec). 

There  are  two  sets  of  measurements  in  Table  III,  the  second  and  third  columns 

★ 

show  bandwidth  for  a self-looped  LSI-11  running  TCP0,  and  the  fourth  and 
fifth  columns  show  the  same  measurements  for  TCP0  running  on  a PDP-11/20. 

Linear  regression  fitting  produces  equations  (1)  and  (2),  relating  letter 
length  and  delay  per  letter.  All  figures  are  for  real  data  bandwidth, 
exclusive  of  the  TCP  header  overhead  (or  any  lower  level  control  overhead). 


* Internal  software  loop  in  TCP0. 


Letter 

size 

(in  bytes) 

Letters 

per 

second 

(LSI-11) 

Bits 

per 

second 

(LSI-11) 

Letters 

per 

second 

(PDP-11/20) 

Bits 

per 

second 

(PDP-11/20) 

1 

246.2 

1970 

377 

3016 

10 



171.8 

13745 

257 

' 

20590 

40 

85.2 

27248 

124.5 

39845 

80 

50.8 

32480 

73.5 

47018 

120 

36.2 

34768 

52.3 

50208 

TCP0  Bandwidth 
TABLE  III 


v 

rt 


* 

f 

i 

« 

f 
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ZJZ. 


Da(L)  » 3.86  + . 1 96L  msec.  (1) 

Db(L)  = 2.51  + . 1 28L  msec  (2) 

where  A = TCP0  on  LSI-11/03 

B = TCP0  on  PDP-11/20 
L = length  of  letter  text  in  8 bit  bytes 
D(L)  = delay  in  milliseconds  for  letters  of  text  length  L 


The  ratio  of  D^  ( L ) / Dg ( L ) tends,  in  the  limit  (for  large  L)  to  1.42, 
which  gives  an  approximate  speed  ratio  of  1.4  to  1 in  favor  of  the 
PDP-11/20.  Comparable  performance  figures  for  the  MCCU  are  given  in  the 


next  section. 
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In  Table  IV,  we  show  the  effect  of  adding  the  1822  interface,  looping  outgoing 

packets  back  to  the  LSI-11  SCCU.  Interrupt  processing  occurs  for  each  byte  of 

incoming  or  outgoing  data,  so  the  achievable  throughput  drops  dramatically. 

A DMA  interface  would  not  introduce  nearly  as  much  processing  overhead.  The 

second  column,  labeled  "WINDOW"  shows  the  effect  of  a 190  octet  (byte)  window, 

limiting  the  number  of  outstanding  octets  to  that  number.  The  maximum  allowed 

ARPANET  message  was  214  bytes,  so  that  text  in  excess  of  178  bytes  (there  are 

36  bytes  of  internet  header  which  must  be  carried  in  the  ARPANET  message)  will 

be  put  into  several  TCP  internet  packets.  The  third  column,  labeled  "NO  WINDOW" 

had  a window  constraint  of  1300  bytes  and  an  ARPANET  message  size  limit  in 

excess  of  400  bytes.  At  letter  sizes  of  200,  the  maximum  ARPANET  message 
★ 

effect  is  apparent,  since  additional  TCP  headers  are  required  to  carry  the 
letter  segments. 

3 The  Multi-Channel  Control  Unit 
3.1  Physical  Characteristics 

In  section  1,  we  made  reference  to  several  MCCU  configurations  at  SU-DSL, 
BBN,  and  UCL.  We  also  suggested  in  section  2 that  the  SCCU  at  SU-DSL  might  be 
upgraded  to  MCCU  capability.  We  are  only  in  a position  to  describe  accurately 
our  experiences  with  the  TCP  on  our  DEC  PDP-11/20,  and  this  section  of  the 
report  will  concentrate  on  this  particular  implementation.  The  SU-DSL  TCP 
is  written  in  BCPL,  and  is  designed  to  run  as  a collection  of  processes  under 
the  ELF  operating  system. 


* for  the  WINDOW  case. 
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LSI-11  SCCU  Bandwidth  (with  1822  adaptor) 


Letter  size  (in  bytes) 

WINDOW 
DATA  RATE 
(letters/sec) 
[bits/sec] 

NO  WINDOW 
DATA  RATE 

1 

73.1  [584] 

73.3  [586] 

10 

59.2  [4735] 

20 

48.2  [7719] 

40 

35.2  [11277] 

35.3  [11296] 

60 

27.7  [13308] 

80 

20.4  [13082] 

22.9  [14640] 

160 

10.4  [13333] 

13.4  [17195] 

200 

7.8  [12440] 

240 

6.9  [13312] 

9.5  [18304] 

320 

5.2  [13355] 

7.4  [18880] 

400 

4.1  [13093] 

6.0  [19253] 

TABLE  IV 

s 

f 
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The  physical  characteristics  of  the  SU-DSL  PDP-11/20  are  shown  below: 

1.  PDP-11/20  CPU 

2.  28K  16  bit  words  (12K  core,  16K  RAM) 

3.  ARPANET  Very  Distant  Host  Interface 

4.  PRNET  DEC  IMP-11  A 1822  interface 

5.  KSR  33  control  TTY 

6.  2 dial-up  modem  ports  (DCll's) 

7.  2 hard-wired  TTY  ports  (DCll's) 

8.  OMRON  CRT  terminal  with  8K  bytes  of  memory 

9.  Two  DECTAPE  units 

10.  1 RS64  64K  word  fast  drum 

11.  1 Diablo  44  dual  platter  5.6  byte  disk 

The  very  distant  host  interface  is  connected  to  the  SUMEX  IMP  through  a 
modem  emulator  [17]  built  at  SU-DSL.  This  emulator  is  capable  of  speeds  up 
to  50K  bits/sec. 

The  software  organization  of  the  MCCU  is  shown  below  in  Table  V.  The  VDH  RTP 
realizes  a "reliable  transmission  protocol"  for  line  control  over  the  host/IMP 
modem  channel.  The  Exerciser  is  a program  which  allows  the  creation  of  traffic 
sources  and  sinks  to  test  TCP  performance.  The  FLEA  debugger  is  a useful  tool 
both  for  debugging  and  for  setting  up  unusual  TCP  test  conditions. 

A complete  MCCU  would  probably  not  contain  FLEA  or  the  Exerciser.  The  ELF  Kernel 
might  be  replaced  by  a simpler  process  manager.  A host/MCCU  interface  would 


have  to  be  included. 
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SU-DSL  MCCU  Software  Configuration 
(all  figures  in  decimal  16  bit  words) 


(a) 

free  storage 

1 ,900 

words 

(b) 

ELF  kernel 

8,500 

words 

(c) 

FLEA  debugger 

1 ,000 

words 

(d) 

Exerciser 

2,400 

words 

(e) 

TCP  system 

13,000 

words 

(f) 

VDH  RTP 
TOTAL 

1 ,300 
28,100 

words 

words 

TABLE  V 


t 
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According  to  the  authors  of  the  BCPL  compiler  for  the  PDP-11  [6,7],  the  space 
penalty  for  use  of  the  higher  level  language  is  a factor  of  2.  Thus,  repro- 
gramming in  assembly  language  might  reduce  the  size  of  the  TCP  proper  to  about 
7200  words.  We  note,  also,  that  procedure  calls  with  parameters  are  expensive 
in  BCPL.  The  use  of  global  variables  and  fewer  procedure  calls  might  further 
reduce  the  program  to  6000  words  or  less.  We  have  learned,  from  our  BCPL 
exposure,  that  high  level  languages  are  sometimes  tricky,  owing  to  wide  varia- 
tions in-the  cost  of  some  programming  facilities. 

We  can  estimate  the  approximate  size  of  a general  purpose  MCCU.  We  will 
assume  a much  simpler  operating  system,  and  the  recoding  of  the  TCP  in  a more 
efficient  manner.  The  Host  specific  interface  and  the  MCCU/Autodin  II  inter- 
faces we  will  assume  are  about  as  complex  as  the  RTP.  Table  VI  illustrates 
the  breakdown. 

Any  reasonable  MCCU  ought  to  fit  in  a 32K  word  system,  including  substantial 
buffer  storage. 

For  completeness,  we  illustrate  in  Table  VII  the  software  breakdown  of  the 
SU-DSL  BCPL  TCP. 


It  is  quite  clear  that  the  incoming  packet  reception  software  is  the  bulkiest 
module.  All  error  handling  and  much  of  the  state  changing  for  connection 
status  occur  in  this  module,  accounting,  in  part,  for  its  size. 

3.2  MCCU  Cost  Estimates 

Estimates  for  MCCU  cost  are  made  somewhat  difficult  because  the  choice 
of  CPU  depends  on  the  bandwidth  required  by  the  host  which  the  MCCU  interfaces 
to  Autodin  II.  Similarly,  the  H0ST/MCCU  interface  cost  may  vary  dramatically 
from  a few  hundred  to  several  thousands  of  dollars.  We  can  reasonably  assume 


DCA-SCCU/MCCU  Table  VI 


General  MCCU  Software  Configuration 
(all  figures  in  decimal  16  bit  words) 


(a) 

free  storage 

16000 

(b) 

operating  system 

4000 

(c) 

TCP 

6000 

(d) 

Host  specific  interface 

2000 

(e) 

Autodin  II  interface 

2000 

TOTAL 

30000 

TABLE  VI 


DCA-SCCU/MCCU  Table  VII 


BCPL  TCP  Organization 
(all  figures  in  decimal  16  bit  words) 


(a) 

Initialization  code 

203 

(b) 

Service  routines 

1583 

(c) 

User  interfaces 

1849 

(d) 

Letter  sending 

1490 

(e) 

Letter  reception 

987 

(f) 

Packet  reception 

3726 

(9) 

Packet  retransmission 

1007 

(h) 

ELF  interfaces 

1253 

(i) 

Network  interface 

900 

TOTAL  1 3000 


TABLE  VII 
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DMA  channels  from  host/MCCU  and  MCCU/network.  Memory  costs  are  estimated  at 
$. 01/bit.  CPU  cost  is  based  on  LSI-11/03  technology.  Table  VIII  shows  the 
details.  Even  doubling  the  CPU  cost  leaves  the  total  under  $15,000. 

3.3  MCCU  Performance 

Our  performance  measurements  on  the  SU-DSL  TCP  are  quite  revealing.  The 
introduction  of  VDH  and  IMP  processing  delays  have  a s’nnificant  impact  on 
performance.  We  made  a series  of  three  bandwidth  tests  which,  within  the 
(serious)  limitations  of  our  free  buffer  storage,  pushed  the  system  to  its 
capacity.  In  table  IX,  we  illustrate  the  results  for  three  configurations: 

(a)  Internal  TCP  software  loop 

(b)  VDH  modem  loop  (corresponds  to  the  TCP0  1822  loop  test  results) 

(c)  IMP  loop  (TCP  sends  packets  to  itself  through  the  IMP). 


The  TCP  parameters  were  adjusted  so  that  maximum  length  ARPANET  messages  were 
permitted  [up  to  8000  bits  of  text],  and  the  flow  control  window  was  opened 
to  permit  up  to  2048  bytes  to  be  in  transit  at  one  time.  The  column  labeled 
"SENDS  outstanding"  indicates  how  many  letters  ahead  the  transmit  side  is 
permitted  to  get  before  requiring  an  acknowledgment  that  a SEND  is  done.  The 
"RECEIVES  outstanding"  indicates  whether  double  input  buffering  is  in  effect. 
The  bandwidth  figures  for  bits/second  refer  to  data  only,  not  overhead  bits 

k 

for  header,  line  control,  etc. 

n 


It  is  evident  that  our  implementation  of  the  VDH  reliable  transmission  protocol 
introduces  substantial  delay  and  consequently  reduces  throughput  [In  our  imple- 
mentation, the  TCP  interface  to  the  RTP  blocks  until  the  ARPANET  message  (en- 
closing the  TCP  internet  packet)  has  been  sent  out  the  line.  This  introduces 
substantial  idle  time  during  which  the  TCP  sending  side  is  blocked.  We  are 

rewriting  this  interface  to  eliminate  the  effect]. 

(Revised  July  10,  1976) 


DCA-SCCU/MCCU  Table  VIII 


GENERAL  MCCU  COST  ESTIMATE 


1. 

LSI-11/03  + 4K  memory  + DLV-11 

$2500 

2. 

Additional  24K  memory 

3750 

3. 

16  bit  DMA  host  interface 

1000 

4. 

16  bit  DMA  parallel/serial 
modem  interface 

5000 

TOTAL 

$12,250 

TABLE  VIII 


DCA-SCCU/MCCU  Table  IX 


TCP  BANDWIDTH  TESTS 


;ter  Size 
i bytes 

SEND 

outstanding 

RECEIVES 

outstanding 

IMP  LOOP 
letters/sec 
[bits/sec] 

VDH  LOOP 
letters/sec 
[bits/sec] 

TCP  LOOP 
letters/sec 
[bits/sec] 

1 

15 

2 

7.5 

[60] 

11.5 

[92] 

-- 

1 

10 

2 

7.7 

[62] 

10.2 

[82] 

14.8 

[118] 

10 

10 

2 

8.0 

[640] 

7.2 

[576] 

18.1 

[1448] 

40 

10 

2 

7.1 

[2272] 

8.3 

[2656] 

13.3 

[4256] 

80 

10 

2 

6.9 

[4352] 

9.9 

[6336] 

— 

80 

8 

2 

-- 

9.0 

[5760] 

— 

80 

5 

2 

— 

6.4 

[4096] 

12.7 

[8128] 

120 

8 

2 

5.0 

[4800] 

-- 

— 

120 

5 

2 

-- 

6.3 

[6048] 

12.4 

[11,904] 

160 

4 

2 

4.3 

[5504] 

5.4 

[6912] 

15.2 

[19,456] 

200 

4 

2 

4.5 

[7200] 

6.0 

[9600] 

11.1 

[17,760] 

200 

3 

2 

— 

6.9 

[11040]  14.8 

[23,680] 

200 

2 

2 

— 

6.3 

[10,080]12.9 

[20,640] 

300 

3 

2 

3.8 

[9120] 

5.5 

[13, 200]  1 3.4 

[32,160] 

300 

3 

1 

3.3 

[7920] 

— 

— 

400 

2 

1 

2.7 

[8640] 

4.0 

[12,400]  9.9 

[31 ,680] 

400 

1 

1 

1.7 

[5440] 

— 

— 

TABLE  IX 
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Adding  the  IMP  into  the  loop  clearly  introduces  additional  delay  for  the 
RTP.  Since  the  RTP  only  uses  a "WINDOW"  of  2 packets  (two  logical  channels), 
any  delay  for  acknowledgment  from  the  IMP  can  lead  to  blocking  of  the  RTP 
channel.  We  plan  to  revise  the  TCP/RTP  interface  to  be  asynchronous  and 
non-blocking  to  obtain  better  TCP/RTP  overlap.  One  hopes  that  the  ADCCP 
line  control  procedure  will  allow  a sufficient  number  of  outstanding  packets 
(say  8-16)  to  avoid  the  possibility  of  bottlenecking. 

4.0  Conclusions 

Although  we  have  not  stressed  the  point  in  this  note,  the  TCP  system  is 
extremely  robust,  able  to  recover  from  network  failures  and  even  the  crash  of 
a remote  host.  It  is  able  to  "clean-up"  half-open  connections  which  it  dis- 
covers, if  it  should  crash  and  later  attempt  to  re-establish  the  connection. 

The  dollar  cost  of  building  SCCU's  and  MCCU's  for  Autodin  II  appears  very 
modest.  Our  performance  analyses  indicate  that  any  interface  to  Autodin  II 
should  employ  DMA  techniques,  and  that  the  line  control  procedure  between 
the  SCCU  [MCCU]  and  the  host  [Autodir.  TI  Packet  Switch]  should  allow  ample 
number  of  outstanding  packets  [segments]  to  overcome  local  processing  delays. 

The  implementation  of  the  MCCU,  if  done  in  a higher  level  language,  such  as 
BCPL,  PASCAL,  will  require  great  care,  to  avoid  some  of  the  unexpected  over- 
head of  higher  level  language  compilation. 

* Revised  July  10,  1976 
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